refactor: read and write config toml in TypeScript by christierney · Pull Request #3662 · posit-dev/publisher

christierney · 2026-03-06T23:04:36Z

Intent

Migrate configuration reading and writing from Go API calls to a pure TypeScript toml module in the VSCode extension. This removes three HTTP round-trips to the Go backend for operations that only need local file I/O, and moves us toward reducing the extension's dependency on the Go subprocess.

Fixes #3651
Fixes #3652
Fixes #3653

Type of Change

Refactor
Bug fix (schema misspelling)

Approach

Updated type definitions and the schema to match current behavior:

Consolidated TS types to match Go and schema (remove dead types/fields, add missing ones)
Removed dead Go types (Schedule, AccessType, ConnectAccessControl) and unreachable code in content.go
Fixed schema: auth_type in integration_requests (was camelCase), add additionalProperties: false to integration_requests items

Added a new src/toml/ module with seven files:

errors.ts — ConfigurationLoadError class and error factory functions
convertKeys.ts — Bidirectional snake_case ↔ camelCase key conversion, preserving user-defined keys in environment and integration_requests[].config
compliance.ts — Port of Go's ForceProductTypeCompliance() for Connect Cloud
loader.ts — Reads TOML, validates against the JSON schema (using ajv), applies defaults
writer.ts — Validates, converts to snake_case, strips empty leaf values, writes TOML
discovery.ts — File discovery (listConfigFiles), single/batch/recursive loading, path resolution
validate.ts — Shared setup for TOML validator function

The public API surface is five exports: loadConfiguration, loadAllConfigurations, loadAllConfigurationsRecursive, writeConfigToFile, and ConfigurationLoadError. Internal helpers stay exported on their source files for intra-module use and tests, but are not re-exported from the barrel.

All functions that produce Configuration objects accept (projectDir, rootDir) where projectDir is relative (e.g., "." or "subdir") and rootDir is the absolute workspace root. Path resolution to absolute paths for file I/O happens inside the module. This matches the Go convention where ProjectDirFromRequest resolves relative dir parameters against the workspace base.

After replacing all callsites, the three Go API handlers (GET /configurations, GET /configurations/{name}, PUT /configurations/{name}) and their tests were deleted. The shared configDTO/configLocation types remain as they're used by other endpoints.

A copy of the JSON schema is bundled at src/toml/schemas/posit-publishing-schema-v3.json, identical to the Go source of truth. A comment in the schema test notes the need to keep them in sync.

Key design decisions:

No intermediate store — callsites call toml functions directly
Writer returns the written Configuration — no write-then-read round-trip
Loader throws on error; discovery functions catch and collect errors for the UI
src/toml/ has no vscode imports — it's pure Node.js
stripEmpty only removes leaf values (undefined, null, empty strings), never parent objects, because the schema conditionally requires section headers like [r] even when all fields are empty

User Impact

No user-facing behavior change. Configuration reading and writing now happens directly in the extension process instead of through HTTP calls to the Go backend.

Automated Tests

[ed: there's probably more now, I've made some improvements since ]

a bunch of new tests in src/toml/:

Key conversion (19 tests) — snake/camel round-trip, preservation of user-defined keys
Schema validation (32 tests) — validates the bundled JSON schema against known valid/invalid configs
Loader (19 tests) — happy path, TOML parse errors, schema errors, defaults, comments, business rules
Writer (14 tests) — round-trip fidelity, snake_case output, comments, stripEmpty, compliance, unknown type handling, empty section preservation
Discovery (22 tests) — file listing, single/batch/recursive loading, relative projectDir, error collection, skip rules
Compliance (13 tests) — cleanup and field modifications based on target product (connect or cloud)
Errors (13 tests) — error factories and formatting of validation error messages

Existing state.test.ts tests were rewritten to mock the toml module instead of the API client.

Directions for Reviewers

I recommend reading through the new toml/ directory first and then reviewing the updates to the extension code.

I am working my way through these manual tests:

Checklist

I have updated the root CHANGELOG.md to cover notable changes.

yes, only for the auth_type schema fix. The rest should not be user-facing.

christierney · 2026-03-09T17:14:50Z

extensions/vscode/src/toml/discovery.ts

+ *
+ * Skips:
+ * - Dot-directories (except .posit itself)
+ * - node_modules, __pycache__, renv, packrat


The Go code has a more complicated setup for excluding files: see https://github.com/posit-dev/publisher/blob/main/internal/bundles/matcher/walker.go

That code is also used for excluding files from bundles, etc. It didn't seem worth implementing all that for just loading configs and the above skiplist seemed sufficient to me, but I'm interested in feedback on this point.

the argument makes sense to me - this is specific to config loading

christierney · 2026-03-09T20:10:19Z

extensions/vscode/src/toml/errors.ts

+ * Filters redundant unevaluatedProperties errors when a more specific
+ * error exists at the same or deeper path (matching Go's behavior).
+ */
+export function formatValidationErrors(errors: ErrorObject[]): string {


This function is attempting to produce useful error messages from TOML validation failures, and to make them match what the Go validator returns (e.g. <key>: not allowed or <key>: missing property). The e2e tests look for these specific error messages. We could decide to let the messages from ajv through if we want, but this keeps the behavior and test changes smaller. In any case we need to do some processing to extract actionable info from the array of validation errors, even if we don't coerce the messages into the Go form.

christierney · 2026-03-09T20:11:26Z

extensions/vscode/src/multiStepInputs/selectNewOrExistingConfig.ts

-      const rawConfigs = response.data;
-      // remove the errors
-      configurations = configurations.filter(
-        (cfg): cfg is Configuration => !isConfigurationError(cfg),


this was redundant as filterConfigurationToValidAndType already filters out errors

christierney · 2026-03-10T16:41:25Z

extensions/vscode/src/multiStepInputs/selectNewOrExistingConfig.ts

+      selectedInspectionResult.configuration.productType = getProductType(
+        activeDeployment.serverType,
+      );


this is a fix for a pre-existing bug I found while testing. This path was not setting a product type, so you'd end up with an invalid config TOML (with 'product_type = '').

The new deployment flow already does this:

publisher/extensions/vscode/src/multiStepInputs/newDeployment.ts

Lines 856 to 857 in 9367e0f

newDeploymentData.entrypoint.inspectionResult.configuration.productType =

getProductType(newOrSelectedCredential.serverType);

zackverham · 2026-03-10T18:26:58Z

.github/workflows/pull-request.yaml

 on:
  pull_request:
  workflow_dispatch:
+    inputs:


thanks for fixing this!

zackverham · 2026-03-10T18:36:07Z

extensions/vscode/src/toml/discovery.ts

+
+/**
+ * Compute a relative projectDir from an absolute path, using "." for the root.
+ * Matches Go's convention where projectDir is relative to the workspace root.


Go reference out of date?

I don't think it's out of date, but maybe not very useful? The point was that we have to match what the Go API expects (use a relative path) when calling it with a directory argument. So when we construct a Configuration object we also give it a relative projectDir that ends up getting passed to a bunch of API calls.

ah, I see - yeah, I wonder if we'll end up with a bunch of out of date Go comments by the end of this that we'll have to sweep out (which is fine)

Yeah my feeling is that they will provide guidance for us and Claude while the migration is ongoing, and then we can sweep through and delete them.

If we need to remember to do that, can we have a "clean up" issue where we make a note of this? Don't want to forget, there's a lot changing.

#3691

I'll start adding specific line references to this

zackverham · 2026-03-10T18:37:10Z

extensions/vscode/src/toml/discovery.ts

+  return rel === "" ? "." : rel;
+}
+
+async function loadConfigsFromPaths(


maybe useful to have code comments for this helper? The Promise of an array of Config | ConfigurationError is confusing if you didn't read about it in a different code comment.

zackverham · 2026-03-10T18:39:15Z

extensions/vscode/src/toml/discovery.ts

+    const relDir = relativeProjectDir(dir, rootDir);
+    const configPaths = await listConfigFiles(dir);
+    const configs = await loadConfigsFromPaths(configPaths, relDir);
+    results.push(...configs);


this would be silly, but what would be the correct behavior if you have nested .posit directories?

IMO if you have a .posit in your .posit you are doing something nonstandard and we should not support it

Agreed I wouldn't expect to see a .posit dir inside a .posit dir at any point.

Add a TypeScript-native TOML configuration loader that matches Go's config.FromFile behavior, as a building block for migrating away from the Go backend. - Add smol-toml, ajv, ajv-formats dependencies for TOML parsing and JSON Schema validation - Create src/toml/ module: loader, key converter, error factories, and JSON schema copy - Consolidate TS types to match Go and schema (remove dead types/fields, add missing ones) - Remove dead Go types (Schedule, AccessType, ConnectAccessControl) and unreachable code in content.go - Fix schema: auth_type in integration_requests (was camelCase), add additionalProperties: false to integration_requests items Fixes #3651 Fixes #3652 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Co-authored-by: Jordan Jensen <jordan.jensen@posit.co>

…rror union

Complete the toml module with: - convertKeysToSnakeCase: reverse of camelCase converter for writing TOML - forceProductTypeCompliance: port of Go's compliance logic for Connect Cloud - writeConfigToFile: validates, transforms, and writes config TOML files - discovery functions: listConfigFiles, loadConfiguration, loadAllConfigurations, loadAllConfigurationsRecursive for finding and loading configs from disk - barrel exports in index.ts Also removes unnecessary type assertions across test files, replacing `as ConfigurationLoadError` with `instanceof` checks per project conventions. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Replace all callsites of api.configurations.get, getAll, and createOrUpdate with direct calls to the TypeScript toml module: - state.ts: getSelectedConfiguration uses loadConfiguration, refreshConfigurations uses loadAllConfigurationsRecursive - newDeployment.ts: uses loadAllConfigurations + writeConfigToFile - selectNewOrExistingConfig.ts: uses loadAllConfigurations + writeConfigToFile - homeView.ts: uses loadAllConfigurations with entrypoint filtering Remove get, getAll, and createOrUpdate from Configurations API class (inspect is kept as it still requires the Go backend). Update state.test.ts to mock toml module instead of API client. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

The toml module was storing absolute paths in Configuration.projectDir, but the Go backend's ProjectDirFromRequest resolves dir query parameters relative to the workspace root. This caused 404 errors from Go API endpoints (files, secrets, packages, etc.) that still receive projectDir. Discovery functions now accept a rootDir parameter and compute relative paths (e.g., "." or "subdir") for Configuration metadata, while using absolute paths internally for file I/O. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

… + rootDir writeConfigToFile now takes (configName, projectDir, rootDir, config) instead of (configPath, projectDir, config), matching the signature pattern of loadConfiguration and loadAllConfigurations. This eliminates the need for callers to compute absolute paths and call getConfigPath separately, removing a class of path-semantic mismatches. getConfigPath is no longer exported. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Remove internal-only symbols (loadConfigFromFile, forceProductTypeCompliance, convertKeysToCamelCase, convertKeysToSnakeCase, getConfigDir, listConfigFiles) from the barrel file. These remain exported on their source files for intra-module use and direct test imports, but are no longer part of the module's public API. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

stripEmpty was removing parent objects (like `r: {}`) after stripping their empty-string children. The JSON schema conditionally requires these sections (e.g., `r` for R content types), so removing them caused validation failures when creating new R Shiny configurations. Go's TOML encoder writes section headers like `[r]` even when all fields are omitted via omitempty. Match that behavior by only stripping leaf values (undefined, null, empty strings), never parent objects. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

…tions Error location strings in getSummaryStringFromError still referenced the removed Go API methods (configurations.getAll, configurations.createOrUpdate). Updated to reference the toml module functions that replaced them. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

These endpoints are no longer called by the extension — configuration reading and writing is now handled by the TypeScript toml module. Deletes: - GET /api/configurations (GetConfigurationsHandlerFunc) - GET /api/configurations/{name} (GetConfigurationHandlerFunc) - PUT /api/configurations/{name} (PutConfigurationHandlerFunc) Retains configDTO and configLocation types in get_configurations.go as they are still used by other handlers (files, secrets, integration requests). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

These directories can be large in Python/R projects and will never contain .posit/publish/ configuration files. Skipping them avoids unnecessary filesystem traversal. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Format ajv validation errors with "key: problem" style matching Go's jsonschema library (e.g., "invalidParam: not allowed." instead of "must NOT have unevaluated properties"). Also drop the file path prefix from the error msg field, matching Go's AgentError format. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

…ionErrors Port Go's entrypointObjectRef handling to TypeScript compliance: - For Connect, copy entrypointObjectRef to entrypoint (object-reference style) - Always clear entrypointObjectRef before validation (non-TOML field) - Delete entrypointObjectRef in writer alongside comments/alternatives Move formatValidationErrors from loader.ts to errors.ts so both loader and writer produce Go-compatible schema error messages. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

The redundancy filter was using pathKey (the parent object path from ajv's instancePath) for prefix comparison. For root-level errors, pathKey is "" which matches everything, incorrectly dropping unevaluatedProperties errors whenever any other error existed. Use fullKey (including the property name) to match Go's behavior, where InstanceLocation points to the property itself. Now only a deeper error at "python.garbage.something" filters out the "python.garbage: not allowed." error. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

…checks workspaces.path() returns string | undefined. Four call sites used the non-null assertion (!) assuming a workspace must be open. Replace with explicit undefined checks and early returns, matching the existing pattern in state.ts. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

… depth limit Parallelize config file loading with Promise.allSettled, eliminate an extra fs.stat per directory by checking readdir entries, remove the abs→rel→abs path round-trip in walkForConfigs, and add a depth limit (20) to prevent runaway walks in pathological directory trees. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

… last Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Add a local loadError closure that captures location, replacing 4 repeated new ConfigurationLoadError(createConfigurationError(..., location)) patterns with single-line throw statements. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Extract shared convertKeys() helper that both convertKeysToCamelCase and convertKeysToSnakeCase delegate to, eliminating near-identical code. In writer.ts, reuse getConfigPath from discovery and add loadError closure matching the loader.ts pattern. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

The "Create New Configuration For Destination" command was writing configs with product_type = '' because the Go inspect API doesn't populate productType. The newDeployment flow already derived it from the credential's serverType via getProductType — apply the same pattern here using activeDeployment.serverType. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

zackverham · 2026-03-10T20:54:16Z

extensions/vscode/src/multiStepInputs/selectNewOrExistingConfig.ts

-      const existingNames = (
-        await api.configurations.getAll(selectedInspectionResult.projectDir)
-      ).data.map((config) => config.configurationName);
+      const root = workspaces.path();


would you mind explaining what this workspaces.path() call is doing? Are we just checking that a workspace path exists at all?

So, the Go API is given the workspace root at startup:

publisher/extensions/vscode/src/servers.ts

Lines 46 to 53 in 4f49e98

const path = workspaces.path();

// Create command to send to terminal stdin

const [command, args] = await commands.create(

context,

path!,

this.port,

this.useKeyChain,

);

And then all of the file handling is done relative to that root. Various API calls expect a "projectDir" path argument that is relative to that root. This gets stored on the Configuration object so that the extension can pass it to the Go APIs.

So any code that loads a config needs to also tell the loader what workspace root it is working from, so the loader can correctly determine relProjectPath.

The other alternative I considered was making a ConfigurationLoader object and injecting it into every part of the extension that needed it, and that singleton would have had an internal reference to the workspace root. But that ended up looking messier.

I'm glad this got asked, because I had the same exact question as you can see by my other comment.

If there's a less confusing way to implement this I'm definitely open to it! Somebody needs to look up the workspace root but it doesn't necessarily have to be done this way.

zackverham · 2026-03-10T21:06:06Z

extensions/vscode/src/toml/convertKeys.ts

+// Keys at these paths contain user-defined names that must not be converted.
+const PRESERVE_KEYS_PATHS = new Set(["environment"]);
+
+// Both camelCase and snake_case forms are checked because the parentKey


can you say a little more about what's going on with this case? The code comment is confusing me a bit.

I originally had completely separate functions for convertKeysToCamelCase and convertKeysToSnakeCase, but they were almost identical, so I extracted the common code into convertKeys. That function needs to check "is the current field I'm looking at the Integration Requests field?" and it needs to work no matter which form (snake_case or camelCase) the object is currently in, so we check both versions of the field name.

I agree I had to read the comment twice, then come to this explanation.

I'll try to rework this comment.

zackverham · 2026-03-10T21:12:55Z

extensions/vscode/src/toml/loader.ts

+}
+
+// Content types that have a mapping in Connect Cloud.
+// Keep in sync with Go's CloudContentTypeFromPublisherType in internal/clients/types/types.go


here's stuff where we probs want some type of tracking ticket to remember to delete these comments - they're useful now but they won't always be.

christierney · 2026-03-10T21:19:31Z

extensions/vscode/src/multiStepInputs/selectNewOrExistingConfig.ts

+      }
+      const allConfigs = await loadAllConfigurations(
+        selectedInspectionResult.projectDir,
+        root,


@zackverham here's where we use the root

dotNomad

This is looking great! I had a few questions and nits. The only thing that needs to be changed prior to merge is the CHANGELOG addition needs to go into Unreleased

dotNomad · 2026-03-10T23:18:18Z

CHANGELOG.md

 ### Fixed

 - Connect Cloud users who have permissions to publish to multiple accounts are able to create credentials again. (#3446)
+- Fixed configuration schema to use `auth_type` (snake_case) for integration requests, matching the format the extension actually produces. Added strict property validation to integration request items. (#3651)


This needs to go into the Unreleased section.

gah! I think this may have happened upon rebasing.

dotNomad · 2026-03-10T23:44:01Z

extensions/vscode/src/toml/convertKeys.ts

+// Keys at these paths contain user-defined names that must not be converted.
+const PRESERVE_KEYS_PATHS = new Set(["environment"]);
+
+// Both camelCase and snake_case forms are checked because the parentKey


I agree I had to read the comment twice, then come to this explanation.

dotNomad · 2026-03-10T23:50:25Z

extensions/vscode/src/multiStepInputs/newDeployment.ts

+    if (!root) {
+      return getDeploymentObjects();
+    }


Can you explain this new code to me?

It looks like it gets the path of the workspace folder, but if there isn't a workspace folder it gets the deployment objects?

I guess this happened prior if api.configurations.getAll failedbecause the catch returns getDeploymentObjects(), but loadAllConfigurations no longer fails if we don't have a workspace folder open?

the getDeploymentObjects() thing threw me too, but this seems to be what the functions in this file do upon error. See all the search results for that func: https://github.com/posit-dev/publisher/blob/main/extensions/vscode/src/multiStepInputs/newDeployment.ts#L129

dotNomad · 2026-03-10T23:52:22Z

extensions/vscode/src/multiStepInputs/selectNewOrExistingConfig.ts

-      const existingNames = (
-        await api.configurations.getAll(selectedInspectionResult.projectDir)
-      ).data.map((config) => config.configurationName);
+      const root = workspaces.path();


I'm glad this got asked, because I had the same exact question as you can see by my other comment.

dotNomad · 2026-03-10T23:55:30Z

extensions/vscode/src/toml/discovery.ts

+    const relDir = relativeProjectDir(dir, rootDir);
+    const configPaths = await listConfigFiles(dir);
+    const configs = await loadConfigsFromPaths(configPaths, relDir);
+    results.push(...configs);


Agreed I wouldn't expect to see a .posit dir inside a .posit dir at any point.

dotNomad · 2026-03-10T23:56:13Z

extensions/vscode/src/toml/discovery.ts

+  rootDir: string,
+  depth: number = 20,
+): Promise<(Configuration | ConfigurationError)[]> {
+  if (depth <= 0) return [];


I expected this to look at this directory for configs, not no looking at all. I could get used to it though, so small nit.

Not sure I follow you. Are you saying the way the recursion terminates is confusing/surprising?

dotNomad · 2026-03-10T23:56:45Z

extensions/vscode/src/toml/discovery.ts

+      name === "node_modules" ||
+      name === "__pycache__" ||
+      name === "renv" ||
+      name === "packrat"


Could be handy to turn this into a const array and check if name is in that array.

christierney changed the title ~~Chris/configurations~~ refactor: read and write config toml in TypeScript Mar 9, 2026

christierney marked this pull request as ready for review March 9, 2026 15:04

christierney requested a review from a team as a code owner March 9, 2026 15:04

christierney mentioned this pull request Mar 9, 2026

feat: add TypeScript TOML config loader and consolidate types #3655

Closed

7 tasks

christierney commented Mar 9, 2026

View reviewed changes

christierney marked this pull request as draft March 9, 2026 18:08

christierney commented Mar 9, 2026

View reviewed changes

christierney marked this pull request as ready for review March 9, 2026 23:21

christierney force-pushed the chris/configurations branch from 56943cb to 745207f Compare March 10, 2026 00:42

christierney commented Mar 10, 2026

View reviewed changes

zackverham reviewed Mar 10, 2026

View reviewed changes

.github/workflows/pull-request.yaml

on:

pull_request:

workflow_dispatch:

inputs:

Copy link

Collaborator

zackverham Mar 10, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks for fixing this!

zackverham reviewed Mar 10, 2026

View reviewed changes

christierney and others added 15 commits March 10, 2026 15:35

remove unnecessary type assertion

f181b66

Co-authored-by: Jordan Jensen <jordan.jensen@posit.co>

remove a couple other unneeded Record types

7e081b6

refactor: loader throws ConfigurationLoadError instead of returning e…

fd817b6

…rror union

style: fix prettier formatting in state.test.ts

9be0e77

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

christierney and others added 11 commits March 10, 2026 15:35

refactor: reorder discovery.ts with public API first, private helpers…

f07d55d

… last Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

refactor: deduplicate Ajv schema setup into shared validate module

36d1e2a

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

fix: add missing await to satisfy require-await lint rule

836264a

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

ci: pass debug_cypress input to e2e workflow from pull-request

a7b0521

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

christierney force-pushed the chris/configurations branch from 4bd46f9 to ae8edc6 Compare March 10, 2026 19:37

docs: add comment explaining loadConfigsFromPaths error handling

25062f6

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

zackverham reviewed Mar 10, 2026

View reviewed changes

zackverham approved these changes Mar 10, 2026

View reviewed changes

christierney commented Mar 10, 2026

View reviewed changes

dotNomad approved these changes Mar 11, 2026

View reviewed changes

	newDeploymentData.entrypoint.inspectionResult.configuration.productType =
	getProductType(newOrSelectedCredential.serverType);

	const path = workspaces.path();
	// Create command to send to terminal stdin
	const [command, args] = await commands.create(
	context,
	path!,
	this.port,
	this.useKeyChain,
	);

Conversation

christierney commented Mar 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Intent

Type of Change

Approach

User Impact

Automated Tests

Directions for Reviewers

Checklist

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

christierney Mar 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dotNomad left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

christierney commented Mar 6, 2026 •

edited

Loading

christierney Mar 9, 2026 •

edited

Loading